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Abstract 


Information-Centric Networking (ICN) is now reaching technological maturity after many years 
of fundamental research and experimentation. This document provides a number of deployment 
considerations in the interest of helping the ICN community move forward to the next step of 
live deployments. First, the major deployment configurations for ICN are described, including the 
key overlay and underlay approaches. Then, proposed deployment migration paths are outlined 
to address major practical issues, such as network and application migration. Next, selected ICN 
trial experiences are summarized. Finally, protocol areas that require further standardization 
are identified to facilitate future interoperable ICN deployments. This document is a product of 
the Information-Centric Networking Research Group (ICNRG). 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the 
results of Internet-related research and development activities. These results might not be 
suitable for deployment. This RFC represents the consensus of the Information-Centric 
Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for 
publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of 
RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8763. 
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1. Introduction 


The ICNRG charter identifies deployment guidelines as an important topic area for the ICN 
community. Specifically, the charter states that defining concrete migration paths for ICN 
deployments that avoid forklift upgrades and defining practical ICN interworking configurations 
with the existing Internet paradigm are key topic areas that require further investigation 
[ICNRGCharter]. Also, it is well understood that results and conclusions from any mid- to large- 
scale ICN experiments in the live Internet will also provide useful guidance for deployments. 


So far, outside of some preliminary investigations, such as [ICN-DEP-CON], there has not been 
much progress on this topic. This document attempts to fill some of these gaps by defining clear 
deployment configurations for ICN and associated migration pathways for these configurations. 
Also, selected deployment trial experiences of ICN technology are summarized. 
Recommendations are also made for potential future IETF standardization of key protocol 
functionality that will facilitate interoperable ICN deployments going forward. 


The major configurations of possible ICN deployments are identified in this document as (1) 
Clean-slate ICN replacement of existing Internet infrastructure, (2) ICN-as-an-Overlay, (3) ICN-as- 
an-Underlay, (4) ICN-as-a-Slice, and (5) Composite-ICN. Existing ICN trial systems primarily fall 
under the ICN-as-an-Overlay, ICN-as-an-Underlay, and Composite-ICN configurations. Each of 
these deployment configurations have their respective strengths and weaknesses. This document 
will aim to provide guidance for current and future members of the ICN community when they 
consider deployment of ICN technologies. 


This document represents the consensus of the Information-Centric Networking Research Group 
(ICNRG). It has been reviewed extensively by the Research Group (RG) members active in the 
specific areas of work covered by the document. 


2. Terminology 


This document assumes readers are, in general, familiar with the terms and concepts that are 
defined in [RFC7927] and [ICN-TERM]. In addition, this document defines the following 
terminology: 


Deployment: 
The final stage of the process of setting up an ICN network that is (1) ready for useful work 
(e.g., transmission of end-user video and text) in a live environment and (2) integrated and 
interoperable with the Internet. We consider the Internet in its widest sense where it 
encompasses various access networks (e.g., Wi-Fi or mobile radio network), service edge 
networks (e.g., for edge computing), transport networks, Content Distribution Networks 
(CDNs), core networks (e.g., mobile core network), and back-end processing networks (e.g., 
data centers). However, throughout this document, the discussion is typically limited to 
edge networks, core networks, and CDNs, for simplicity. 
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Information-Centric Networking (ICN): 
A data-centric network architecture where accessing data by name is the essential 
network primitive. See [ICN-TERM] for further information. 


Network Functions Virtualization (NFV): 
A networking approach where network functions (e.g., firewalls or load balancers) are 
modularized as software logic that can run on general purpose hardware and, thus, are 
specifically decoupled from the previous generation of proprietary and dedicated 
hardware. See [RFC8568] for further information. 


Software-Defined Networking (SDN): 
A networking approach where the control and data planes for switches are separated, 
allowing for realizing capabilities, such as traffic isolation and programmable forwarding 
actions. See [RFC7426] for further information. 


3. Abbreviations List 


API: 
BIER: 
BoF: 
CCNx: 
CDN: 
CoAP: 


DASH: 


Diffserv: 


Dos: 
DTN: 
ETSI: 
EU: 
FP7: 
HLS: 
HTTP: 
HTTPS: 
H2020: 
ICN: 
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Application Programming Interface 

Bit Index Explicit Replication 

Birds of a Feather (session) 

Content-Centric Networking 

Content Distribution Network 

Constrained Application Protocol 

Dynamic Adaptive Streaming over HTTP 
Differentiated Services 

Denial of Service 

Delay-Tolerant Networking 

European Telecommunications Standards Institute 
European Union 

7th Framework Programme for Research and Technological Development 
HTTP Live Streaming 

HyperText Transfer Protocol 

HyperText Transfer Protocol Secure 

Horizon 2020 (research program) 


Information-Centric Networking 
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ICNRG: 
IETF: 
IntServ: 
IoT: 

IP: 


NDN: 
NETCONF: 
NetInf: 
NFD: 

NFV: 
NICT: 

NR: 

OAM: 
ONAP: 
OSPF: 


PoC: 
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Information-Centric Networking Research Group 
Internet Engineering Task Force 

Integrated Services 

Internet of Things 

Internet Protocol 

Internet Protocol Version 4 

Internet Protocol Version 6 

Internet Protocol Television 

Intermediate System to Intermediate System 
Internet Service Provider 

kilo (1000) 

Layer 2 

Long Term Evolution (or 4th generation cellular system) 
Management and Orchestration 

Multi-access Edge Computing 

Megabits per second 

Machine-to-Machine 

Network Attachment Point 

Named Data Networking 

Network Configuration Protocol 

Network of Information 

Named Data Networking Forwarding Daemon 
Network Functions Virtualization 

Japan's National Institute of Information and Communications Technology 
New Radio (access network for 5G) 

Operations, Administration, and Maintenance 
Open Network Automation Platform 

Open Shortest Path First 


Proof of Concept (demo) 
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POINT: 


qMp: 


REST: 
RESTCONF: 
RIFE: 
RIP: 
ROM: 
RSVP: 
RTP: 
SDN: 
SFC: 
SLA: 
TCL: 
TCP: 
UDP: 
UMOBILE: 
US: 
USA: 
VoD: 
VPN: 
WG: 
YANG: 
5G: 


6LOWPAN: 
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IP Over ICN - the better IP (project) 

Quick Mesh Project 

Quality of Service 

Random Access Memory 

Radio Access Network 

Representational State Transfer (architecture) 
Representational State Transfer Configuration (protocol) 
Architecture for an Internet For Everybody (project) 
Routing Information Protocol 

Read-Only Memory 

Resource Reservation Protocol 

Real-time Transport Protocol 

Software-Defined Networking 

Service Function Chaining 

Service Level Agreement 

Transport Convergence Layer 

Transmission Control Protocol 

User Datagram Protocol 

Universal Mobile-centric and Opportunistic Communications Architecture 
United States 

United States of America 

Video on Demand 

Virtual Private Network 

Working Group 

Yet Another Next Generation (data modeling language) 
Fifth Generation (cellular network) 


IPv6 over Low-Power Wireless Personal Area Networks 


Informational 
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4. Deployment Configurations 


In this section, we present various deployment options for ICN. These are presented as 
"configurations" that allow for studying these options further. While this document will outline 
experiences with a number of these configurations (in Section 6), we will not provide an in-depth 
technical or commercial evaluation for any of them -- for this, we refer to existing literature in 
this space, such as [Tateson]. 


4.1. Clean-Slate ICN 


ICN has often been described as a "clean-slate" approach with the goal to renew or replace the 
complete IP infrastructure of the Internet. As such, existing routing hardware and ancillary 
services, such as existing applications that are typically tied directly to the TCP/IP stack, are not 
taken for granted. For instance, a Clean-slate ICN deployment would see existing IP routers being 
replaced by ICN-specific forwarding and routing elements, such as NFD [NFD], CCNx routers 
[Jacobson], or Publish-Subscribe Internet Technology (PURSUIT) forwarding nodes 
[IEEE_Communications]. 


While such clean-slate replacement could be seen as exclusive for ICN deployments, some ICN 
approaches (e.g., [POINT]) also rely on the deployment of general infrastructure upgrades, in this 
case, SDN switches. Different proposals have been made for various ICN approaches to enable 
the operation over an SDN transport [Reed] [CONET] [C_FLOW]. 


4.2. ICN-as-an-Overlay 


Similar to other significant changes to the Internet routing fabric, particularly the transition 
from IPv4 to IPV6 or the introduction of IP multicast, this deployment configuration foresees the 
creation of an ICN overlay. Note that this overlay approach is sometimes, informally, also 
referred to as a tunneling approach. The overlay approach can be implemented directly (e.g., 
ICN-over-UDP), as described in [CCNx_UDP]. Alternatively, the overlay can be accomplished via 
ICN-in-L2-in-IP as in [[EEE_Communications], which describes a recursive layering process. 
Another approach used in the Network of Information (NetInf) is to define a convergence layer 
to map NetInf semantics to HTTP [NetInf]. Finally, [Overlay_ICN] describes an incremental 
approach to deploying an ICN architecture particularly well suited to SDN-based networks by 
also segregating ICN user- and control-plane traffic. 


However, regardless of the flavor, the overlay approach results in islands of ICN deployments 
over existing IP-based infrastructure. Furthermore, these ICN islands are typically connected to 
each other via ICN/IP tunnels. In certain scenarios, this requires interoperability between 
existing IP routing protocols (e.g., OSPF, RIP, or IS-IS) and ICN-based ones. ICN-as-an-Overlay can 
be deployed over the IP infrastructure in either edge or core networks. This overlay approach is 
thus very attractive for ICN experimentation and testing, as it allows rapid and easy deployment 
of ICN over existing IP networks. 
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4.3. ICN-as-an-Underlay 


Proposals, such as [POINT] and [White], outline the deployment option of using an ICN underlay 
that would integrate with existing (external) IP-based networks by deploying application-layer 
gateways at appropriate locations. The main reasons for such a configuration option is the 
introduction of ICN technology in given islands (e.g., inside a CDN or edge IoT network) to reap 
the benefits of native ICN, in terms of underlying multicast delivery, mobility support, fast 
indirection due to location independence, in-network computing, and possibly more. The 
underlay approach thus results in islands of native ICN deployments that are connected to the 
rest of the Internet through protocol conversion gateways or proxies. Routing domains are 
strictly separated. Outside of the ICN island, normal IP routing protocols apply. Within the ICN 
island, ICN-based routing schemes apply. The gateways transfer the semantic content of the 
messages (i.e., IP packet payload) between the two routing domains. 


4.3.1. Edge Network 


Native ICN networks may be located at the edge of the network where the introduction of new 
network architectures and protocols is easier in so-called greenfield deployments. In this context, 
ICN is an attractive option for scenarios, such as IoT [ICN-IoT]. The integration with the current 
IP protocol suite takes place at an application gateway/proxy at the edge network boundary, e.g., 
translating incoming CoAP request/response transactions [RFC7252] into ICN message exchanges 
or vice versa. 


The work in [VSER] positions ICN as an edge service gateway driven by a generalized ICN-based 
service orchestration system with its own compute and network virtualization controllers to 
manage an ICN infrastructure. The platform also offers service discovery capabilities to enable 
user applications to discover appropriate ICN service gateways. To exemplify a scenario in a use 
case, the [VSER] platform shows the realization of a multi-party audio/video conferencing service 
over such an edge cloud deployment of ICN routers realized over commodity hardware 
platforms. This platform has also been extended to offer seamless mobility as a service that 
[VSER-Mob] features. 


4.3.2. Core Network 


In this suboption, a core network would utilize edge-based protocol mapping onto the native ICN 
underlay. For instance, [POINT] proposes to map HTTP transactions or some other IP-based 
transactions, such as CoAP, directly onto an ICN-based message exchange. This mapping is 
realized at the NAP, for example, in access points or customer premise equipment, which, in 
turn, provides a standard IP interface to existing user devices. Thus, the NAP provides the 
apparent perception of an IP-based core network toward any external peering network. 


The work in [White] proposes a similar deployment configuration. There, the goal is to use ICN 
for content distribution within CDN server farms. Specifically, the protocol mapping is realized at 
the ingress of the server farm where the HTTP-based retrieval request is served, while the 
response is delivered through a suitable egress node translation. 
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4.4. ICN-as-a-Slice 


The objective of network slicing [NGMN-5G] is to multiplex a general pool of compute, storage, 
and bandwidth resources among multiple service networks with exclusive SLA requirements on 
transport and compute-level QoS and security. This is enabled through NFV and SDN technology 
functions that enable functional decomposition (hence, modularity, independent scalability of 
control, and/or the user-plane functions), agility, and service-driven programmability. Network 
slicing is often associated with 5G but is clearly not limited to such systems. However, from a 5G 
perspective, the definition of slicing includes access networks enabling dynamic slicing of the 
spectrum resources among various services, hence naturally extending itself to end points and 
cloud resources across multiple domains, to offer end-to-end guarantees. Once instantiated, these 
slices could include a mix of connectivity services (e.g., LTE-as-a-service), Over-the-Top (OTT) 
services (e.g., VoD), or other IoT services through composition of a group of virtual and/or 
physical network functions at the control-, user-, and service-plane levels. Such a framework can 
also be used to realize ICN slices with its own control and forwarding plane, over which one or 
more end-user services can be delivered [NGMN-Network-Slicing]. 


The 5G next generation architecture [fiveG-23501] provides the flexibility to deploy the ICN-as-a- 
Slice over either the edge (RAN) or mobile core network; otherwise, the ICN-as-a-Slice may be 
deployed end to end. Further discussions on extending the architecture presented in 
[fiveG-23501] and the corresponding procedures in [fiveG-23502] to support ICN has been 
provided in [ICN-5GC]. The document elaborates on two possible approaches to enable ICN: (1) as 
an edge service using the local data network (LDN) feature in 5G using User Plane Function (UPF) 
classification functions to fast handover to the ICN forwarder and (2) as a native deployment 
using the non-IP Protocol Data Unit (PDU) support that would allow new network layer PDU to be 
handed over to ICN UPFs collocated with the Generation NodeB (gNB) functions without invoking 
any IP functions. While the former deployment would still rely on 3GPP-based mobility 
functions, the later would allow mobility to be handled natively by ICN. However, both these 
deployment modes should benefit from other ICN features, such as in-network caching and 
computing. Associated with this ICN user-plane enablement, control-plane extensions are also 
proposed leveraging 5th Generation Core Network (5GC)'s interface to other application 
functions (AFs) to allow new network service-level programmability. Such a generalized network 
slicing framework should be able to offer service slices over both IP and ICN. Coupled with the 
view of ICN functions as being "service function chaining" [RFC7665], an ICN deployment within 
such a slice could also be realized within the emerging control plane that is targeted for adoption 
in future (e.g., 5G mobile) network deployments. Finally, it should be noted that ICN is not 
creating the network slice but instead that the slice is created to run a 5G-ICN instance 
[Ravindran]. 


At the level of the specific technologies involved, such as ONAP [ONAP] (which can be used to 
orchestrate slices), the 5G-ICN slice requires compatibility, for instance, at the level of the 
forwarding/data plane depending on if it is realized as an overlay or using programmable data 
planes. With SDN emerging for new network deployments, some ICN approaches will need to 
integrate as a data-plane forwarding function with SDN, as briefly discussed in Section 4.1. 
Further cross-domain ICN slices can also be realized using frameworks, such as [ONAP]. 
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4.5. Composite-ICN Approach 


Some deployments do not clearly correspond to any of the previously defined basic 
configurations of (1) Clean-slate ICN, (2) ICN-as-an-Overlay, (3) ICN-as-an-Underlay, and (4) ICN- 
as-a-Slice. Or, a deployment may contain a composite mixture of the properties of these basic 
configurations. For example, the Hybrid ICN [H-ICN_1] approach carries ICN names in existing 
IPv6 headers and does not have distinct gateways or tunnels connecting ICN islands or any other 
distinct feature identified in the previous basic configurations. So we categorize Hybrid ICN and 
other approaches that do not clearly correspond to one of the other basic configurations as a 
Composite-ICN approach. 


5. Deployment Migration Paths 


We now focus on the various migration paths that will have importance to the various 
stakeholders that are usually involved in the deployment of ICN networks. We can identify these 
stakeholders as: 


e application providers 


e ISPs and service providers, both as core and access network providers, as well as ICN 
network providers 


e CDN providers (due to the strong relation of the ICN proposition to content delivery) 
e end-device manufacturers and users 


Our focus is on technological aspects of such migration. Economic or regulatory aspects, such as 
those studied in [Tateson], [Techno_Economic], and [Internet_Pricing], are left out of our 
discussion. 


5.1. Application and Service Migration 


The Internet supports a multitude of applications and services using the many protocols defined 
over the packet-level IP service. HTTP provides one convergence point for these services with 
many web development frameworks based on the semantics provided by it. In recent years, even 
services such as video delivery have been migrating from the traditional RTP-over-UDP delivery 
to the various HTTP-level streaming solutions, such as DASH [DASH] and others. Nonetheless, 
many non-HTTP services exist, all of which need consideration when migrating from the IP- 
based Internet to an ICN-based one. 


The underlay deployment configuration option presented in Section 4.3 aims at providing some 
level of compatibility to the existing ecosystem through a proxy-based message flow mapping 
mechanism (e.g., mapping of existing HTTP/TCP/IP message flows to HTTP/ICN message flows). A 
related approach of mapping TCP/IP to TCP/ICN message flows is described in [Moiseenko]. 
Another approach described in [Marchal] uses HTTP/NDN gateways and focuses, in particular, on 
the right strategy to map HTTP to NDN to guarantee a high level of compatibility with HTTP 
while enabling an efficient caching of data in the ICN island. The choice of approach is a design 
decision based on how to configure the protocol stack. For example, the approach described in 
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[Moiseenko] carries the TCP layer into the ICN underlay, while the [Marchal] approach 
terminates both HTTP and TCP at the edge of the ICN underlay and maps these functionalities 
onto existing ICN functionalities. 


Alternatively, ICN-as-an-Overlay (Section 4.2) and ICN-as-a-Slice (Section 4.4) allow for the 
introduction of the full capabilities of ICN through new application/service interfaces, as well as 
operations in the network. With that, these approaches of deployment are likely to aim at 
introducing new application/services capitalizing on those ICN capabilities, such as in-network 
multicast and/or caching. 


Finally, [ICN-LTE-4G] outlines a dual-stack end-user device approach that is applicable for all 
deployment configurations. Specifically, it introduces middleware layers (called the TCL) in the 
device that will dynamically adapt existing applications to either an underlying ICN protocol 
stack or standard IP protocol stack. This involves end device signaling with the network to 
determine which protocol stack instance and associated middleware adaptation layers to utilize 
for a given application transaction. 


5.2. Content Delivery Network Migration 


A significant number of services and applications are devoted to content delivery in some form, 
e.g., as video delivery, social media platforms, and many others. CDNs are deployed to assist these 
services through localizing the content requests and therefore reducing latency and possibly 
increasing utilization of available bandwidth, as well as reducing the load on origin servers. 
Similar to the previous subsection, the underlay deployment configuration presented in Section 
4.3 aims at providing a migration path for existing CDNs. This is also highlighted in a BIER use- 
case document [BIER], specifically with potential benefits in terms of utilizing multicast in the 
delivery of content but also reducing load on origin and delegation servers. We return to this 
benefit in the trial experiences in Section 6. 


5.3. Edge Network Migration 


Edge networks often see the deployment of novel network-level technology, e.g., in the space of 
IoT. For many years, such IoT deployments have relied, and often still do, on proprietary 
protocols for reasons, such as increased efficiency, lack of standardization incentives, and others. 
Utilizing the underlay deployment configuration in Section 4.3.1, application gateways/proxies 
can integrate such edge deployments into IP-based services, e.g., utilizing CoAP-based [RFC7252] 
M2M platforms, such as oneM2M [oneM2M] or others. 


Another area of increased edge network innovation is that of mobile (access) networks, 
particularly in the context of the 5G mobile networks. Network softwarization (using 
technologies like service orchestration frameworks leveraging NFV and SDN concepts) are now 
common in access networks and other network segments. Therefore, the ICN-as-a-Slice 
deployment configuration in Section 4.4 provides a suitable migration path for the integration of 
non-IP-based edge networks into the overall system by virtue of realizing the relevant (ICN) 
protocols in an access network slice. 
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With the advent of SDN and NFV capabilities, so-called campus or site-specific deployments could 
see the introduction of ICN islands at the edge for scenarios such as gaming or deployments 
based on Augmented Reality (AR) / Virtual Reality (VR), e.g., smart cities or theme parks. 


5.4. Core Network Migration 


Migrating core networks of the Internet or mobile networks requires not only significant 
infrastructure renewal but also the fulfillment of the key performance requirements, 
particularly in terms of throughput. For those parts of the core network that would migrate to an 
SDN-based optical transport, the ICN-as-a-Slice deployment configuration in Section 4.4 would 
allow the introduction of native ICN solutions within slices. This would allow for isolating the 
ICN traffic while addressing the specific ICN performance benefits (such as in-network multicast 
or caching) and constraints (such as the need for specific network elements within such isolated 
slices). For ICN solutions that natively work on top of SDN, the underlay deployment 
configuration in Section 4.3.2 provides an additional migration path, preserving the IP-based 
services and applications at the edge of the network while realizing the core network routing 
through an ICN solution (possibly itself realized in a slice of the SDN transport network). 


6. Deployment Trial Experiences 


In this section, we will outline trial experiences, often conducted within collaborative project 
efforts. Our focus here is on the realization of the various deployment configurations identified 
in Section 4; therefore, we categorize the trial experiences according to these deployment 
configurations. While a large body of work exists at the simulation or emulation level, we 
specifically exclude these studies from our analysis to retain the focus on real-life experiences. 


6.1. ICN-as-an-Overlay 


6.1.1. FP7 PURSUIT Efforts 


Although the FP7 PURSUIT [IEEE_Communications] efforts were generally positioned as a Clean- 
slate ICN replacement of IP (Section 4.1), the project realized its experimental testbed as an L2 
VPN-based overlay between several European, US, and Asian sites, following the overlay 
deployment configuration presented in Section 4.2. Software-based forwarders were utilized for 
the ICN message exchange, while native ICN applications (e.g., for video transmissions) were 
showcased. At the height of the project efforts, about 70+ nodes were active in the (overlay) 
network with presentations given at several conferences, as well as to the ICNRG. 


6.1.2. FP7 SAIL Trial 


The Network of Information (NetInf) is the approach to ICN developed by the EU FP7 Scalable 
and Adaptive Internet Solutions (SAIL) project [SAIL]. NetInf provides both name-based 
forwarding with CCNx-like semantics and name resolution (for indirection and late binding). The 
NetInf architecture supports different deployment options through its convergence layer, such as 
using UDP, HTTP, and even DTN underlays. In its first prototypes and trials, NetInf was deployed 
mostly in an HTTP embedding and in a UDP overlay following the overlay deployment 
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configuration in Section 4.2. [SAIL_Prototyping] describes several trials, including a stadium 
environment and a multi-site testbed, leveraging NetInf's routing hint approach for routing 
scalability [SAIL_Content_Delivery]. 


6.1.3. NDN Testbed 


The Named Data Networking (NDN) is one of the research projects of the National Science 
Foundation (NSF) of the USA as part of the Future Internet Architecture (FIA) Program. The 
original NDN proposal was positioned as a Clean-slate ICN replacement of IP (Section 4.1). 
However, in several trials, NDN generally follows the overlay deployment configuration of 
Section 4.2 to connect institutions over the public Internet across several continents. The use 
cases covered in the trials include real-time videoconferencing, geolocating, and interfacing to 
consumer applications. Typical trials involve up to 100 NDN-enabled nodes [NDN-testbed] 
[angam]. 


6.1.4. ICN2020 Efforts 


ICN2020 is an ICN-related project of the EU H2020 research program and NICT [ICN2020- 
overview]. ICN2020 has a specific focus to advance ICN towards real-world deployments through 
applications, such as video delivery, interactive videos, and social networks. The federated 
testbed spans the USA, Europe, and Japan. Both NDN and CCNx approaches are within the scope 
of the project. 


ICN2020 has released a set of interim public technical reports. The report [ICN2020-Experiments] 
contains a detailed description of the progress made in both local testbeds and federated 
testbeds. The plan for the federated testbed includes integrating the NDN testbed, the CUTEi 
testbed [RFC7945] [CUTEi], and the GEANT testbed [GEANT] to create an overlay deployment 
configuration of Section 4.2 over the public Internet. The total network contains 37 nodes. Since 
video was an important application, typical throughput was measured in certain scenarios and 
found to be in the order of 70 Mbps per node. 


6.1.5. UMOBILE Efforts 


UMOBILE is another of the ICN research projects under the H2020 research program [UMOBILE- 
overview]. The UMOBILE architecture integrates the principles of DTN and ICN in a common 
framework to support edge computing and mobile opportunistic wireless environments (e.g., 
post-disaster scenarios and remote areas). The UMOBILE architecture [UMOBILE-2] was 
developed on top of the NDN framework by following the overlay deployment configuration of 
Section 4.2. UMOBILE aims to extend Internet functionally by combining ICN and DTN 
technologies. 


One of the key aspects of UMOBILE was the extension of the NDN framework to locate network 
services (e.g., mobility management and intermittent connectivity support) and user services 
(e.g., pervasive content management) as close as possible to the end users to optimize bandwidth 
utilization and resource management. Another aspect was the evolution of the NDN framework 
to operate in challenging wireless networks, namely in emergency scenarios [UMOBILE-3] and 
environments with intermittent connectivity. To achieve this, the NDN framework was leveraged 
with a new messaging application called Oi! [UMOBILE-4] [UMOBILE-5], which supports 
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intermittent wireless networking. UMOBILE also implements a new data-centric wireless routing 
protocol, DABBER [UMOBILE-6] [DABBER], which was designed based on data reachability 
metrics that take availability of adjacent wireless nodes and different data sources into 
consideration. The contextual awareness of the wireless network operation is obtained via a 
machine-learning agent running within the wireless nodes [UMOBILE-7]. 


The consortium has completed several ICN deployment trials. In a post-disaster scenario trial 
[UMOBILE-8], a special DTN face was created to provide reachability to remote areas where there 
is no typical Internet connection. Another trial was the ICN deployment over the "Guifi.net" 
community network in the Barcelona region. This trial focused on the evaluation of an ICN edge 
computing platform, called PiCasso [UMOBILE-9]. In this trial, ten (10) Raspberry Pis were 
deployed across Barcelona to create an ICN overlay network on top of the existing IP routing 
protocol (e.g., qMp routing). This trial showed that ICN can play a key role in improving data 
delivery QoS and reducing the traffic in intermittent connectivity environments (e.g., wireless 
community network). A third trial in Italy was focused on displaying the capability of the 
UMOBILE architecture to reach disconnected areas and assist responsible authorities in 
emergencies, corresponding to an infrastructure scenario. The demonstration encompassed 
seven (7) end-user devices, one (1) access point, and one (1) gateway. 


6.2. ICN-as-an-Underlay 


6.2.1. H2020 POINT and RIFE Efforts 


POINT and RIFE are two more ICN-related research projects of the H2020 research program. The 
efforts in the H2020 POINT and RIFE projects follow the underlay deployment configuration in 
Section 4.3.2; edge-based NAPs provide the IP/HTTP-level protocol mapping onto ICN protocol 
exchanges, while the SDN underlay (or the VPN-based L2 underlay) is used as a transport 
network. 


The multicast and service endpoint surrogate benefit in HTTP-based scenarios, such as for HTTP- 
level streaming video delivery, and have been demonstrated in the deployed POINT testbed with 
80+ nodes being utilized. Demonstrations of this capability have been given to the ICNRG, and 
public demonstrations were also provided at events [MWC_Demo]. The trial has also been 
accepted by the ETSI MEC group as a public proof-of-concept demonstration. 


While the aforementioned demonstrations all use the overlay deployment, H2020 also has 
performed ICN underlay trials. One such trial involved commercial end users located in the 
PrimeTel network in Cyprus with the use case centered on IPTV and HLS video dissemination. 
Another trial was performed over the "Guifi.net" community network in the Barcelona region, 
where the solution was deployed in 40 households, providing general Internet connectivity to the 
residents. Standard IPTV Set-Top Boxes(STBs), as well as HLS video players, were utilized in 
accordance with the aim of this deployment configuration, namely to provide application and 
service migration. 
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6.2.2. H2020 FLAME Efforts 


The H2020 Facility for Large-Scale Adaptive Media Experimentation (FLAME) efforts concentrate 
on providing an experimental ground for the aforementioned POINT/RIFE solution in initially 
two city-scale locations, namely in Bristol and Barcelona. This trial followed the underlay 
deployment configuration in Section 4.3.2, as per the POINT/RIFE approach. Experiments were 
conducted with the city/university joint venture Bristol-is-Open (BIO) to ensure the readiness of 
the city-scale SDN transport network for such experiments. Another trial was for the ETSI MEC 
PoC. This trial showcased operational benefits provided by the ICN underlay for the scenario of a 
location-based game. These benefits aim at reduced network utilization through improved video 
delivery performance (multicast of all captured videos to the service surrogates deployed in the 
city at six locations), as well as reduced latency through the play out of the video originating 
from the local NAP, collocated with the Wi-Fi Access Point (AP) instead of a remote server, i.e., the 
playout latency was bounded by the maximum single-hop latency. 


Twenty three (23) large-scale media service experiments are planned as part of the H2020 
FLAME efforts in the area of Future Media Internet (FMI). The platform, which includes the ICN 
capabilities, integrated with NFV and SDN capabilities of the infrastructure. The ultimate goal of 
these platform efforts is the full integration of ICN into the overall media function platform for 
the provisioning of advanced (media-centric) Internet services. 


6.2.3. CableLabs Content Delivery System 


The CableLabs ICN work reported in [White] proposes an underlay deployment configuration 
based on Section 4.3.2. The use case is ICN for content distribution within complex CDN server 
farms to leverage ICN's superior in-network caching properties. This CDN based on “island of 
ICN" is then used to service standard HTTP/IP-based content retrieval requests coming from the 
general Internet. This approach acknowledges that whole scale replacement (see Section 4.1) of 
existing HTTP/IP end-user applications and related web infrastructure is a difficult proposition. 
[White] is clear that the architecture proposed has not yet been tested experimentally but that 
implementations are in process and expected in the 3-5 year time frame. 


6.2.4. NDN IoT Trials 


[Baccelli] summarizes the trial of an NDN system adapted specifically for a wireless IoT scenario. 
The trial was run with 60 nodes distributed over several multistory buildings in a university 
campus environment. The NDN protocols were optimized to run directly over 6LOWPAN wireless 
link layers. The performance of the NDN-based IoT system was then compared to an equivalent 
system running standard IP-based IoT protocols. It was found that the NDN-based IoT system was 
superior in several respects, including in terms of energy consumption and for RAM and ROM 
footprints [Baccelli] [Anastasiades]. For example, the binary file size reductions for NDN protocol 
stack versus standard IP-based IoT protocol stack on given devices were up to 60% less for ROM 
size and up to 80% less for RAM size. 
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6.2.5. NREN ICN Testbed 


The National Research and Education Network (NREN) ICN Testbed is a project sponsored by 
Cisco, Internet2, and the US Research and Education community. Participants include 
universities and US federal government entities that connect via a nationwide VPN-based L2 
underlay. The testbed uses the CCNx approach and is based on the [CICN] open-source software. 
There are approximately 15 nodes spread across the USA that connect to the testbed. The 
project's current focus is to advance data-intensive science and network research by improving 
data movement, searchability, and accessibility. 


6.2.6. DOCTOR Testbed 


The DOCTOR project is a French research project meaning "Deployment and Securisation of new 
Functionalities in Virtualized Networking Environments". The project aims to run NDN over 
virtualized NFV infrastructure [Doctor] (based on Docker technology) and focuses on the NFV 
MANO aspects to build an operational NDN network focusing on important performance criteria, 
such as security, performance, and interoperability. 


The data plane relies on an HTTP/NDN gateway [Marchal] that processes HTTP traffic and 
transports it in an optimized way over NDN to benefit from the properties of the NDN island (i.e., 
by mapping HTTP semantics to NDN semantics within the NDN island). The testbed carries real 
Web traffic of users and has been currently evaluated with the top 1000 most popular websites. 
The users only need to set the gateway as the web proxy. The control plane relies on a central 
manager that uses machine-learning-based detection methods [Mai-1] from the date gathered by 
distributed probes and applies orchestrated countermeasures against NDN attacks [Nguyen-1] 
[Nguyen-2] [Mai-2] or performance issues. A remediation can be, for example, the scale up of a 
bottleneck component or the deployment of a security function, like a firewall or a signature 
verification module. Test results thus far have indicated that key attacks can be detected 
accurately. For example, content poisoning attacks can be detected at up to over 95% accuracy 
(with less than 0.01% false positives) [Nguyen-3]. 


6.3. Composite-ICN Approach 


Hybrid ICN [H-ICN_1] [H-ICN_2] is an approach where the ICN names are mapped to IPv6 
addresses and other ICN information is carried as payload inside the IP packet. This allows 
standard (ICN-unaware) IP routers to forward packets based on IPv6 info but enables ICN-aware 
routers to apply ICN semantics. The intent is to enable rapid hybrid deployments and seamless 
interconnection of IP and Hybrid ICN domains. Hybrid ICN uses [CICN] open-source software. 
Initial tests have been done with 150 clients consuming DASH videos, which showed good 
scalability properties at the server side using the Hybrid ICN transport [H-ICN_3] [H-ICN_2]. 


6.4. Summary of Deployment Trials 


In summary, there have been significant trials over the years with all the major ICN protocol 
flavors (e.g., CCNx, NDN, and POINT) using both the ICN-as-an-Overlay and ICN-as-an-Underlay 
deployment configurations. The major limitations of the trials include the fact that only a limited 
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number of applications have been tested. However, the tested applications include both native 
ICN and existing IP-based applications (e.g., videoconferencing and IPTV). Another limitation of 
the trials is that all of them involve less than 1k users. 


Huawei and China Unicom have just started trials of the ICN-as-a-Slice configuration to 
demonstrate ICN features of security, mobility, and bandwidth efficiency over a wired 
infrastructure using videoconferencing as the application scenario [Chakraborti]; also, this 
prototype has been extended to demonstrate this over a 5G-NR access. 


The Clean-slate ICN approach has obviously never been in trials, as complete replacement of 
Internet infrastructure (e.g., existing applications, TCP/IP protocol stack, IP routers, etc.) is no 
longer considered a viable alternative. 


Finally, Hybrid ICN is a Composite-ICN approach that offers an interesting alternative, as it 
allows ICN semantics to be embedded in standard IPv6 packets so the packets can be routed 
through either IP routers or Hybrid ICN routers. Note that some other trials, such as the DOCTOR 
testbed (Section 6.2.6), could also be characterized as a Composite-ICN approach, because it 
contains both ICN gateways (as in ICN-as-an-Underlay) and virtualized infrastructure (as in ICN- 
as-a-Slice). However, for the DOCTOR testbed, we have chosen to characterize it as an ICN-as-an- 
Underlay configuration because that is a dominant characteristic. 


7. Deployment Issues Requiring Further Standardization 


"Information-Centric Networking (ICN) Research Challenges" [RFC7927] describes key ICN 
principles and technical research topics. As the title suggests, [RFC7927] is research oriented 
without a specific focus on deployment or standardization issues. This section addresses this 
open area by identifying key protocol functionality that may be relevant for further 
standardization effort in the IETF. The focus is specifically on identifying protocols that will 
facilitate future interoperable ICN deployments correlating to the scenarios identified in the 
deployment migration paths in Section 5. The identified list of potential protocol functionality is 
not exhaustive. 


7.1. Protocols for Application and Service Migration 


End-user applications and services need a standardized approach to trigger ICN transactions. For 
example, in Internet and web applications today, there are established socket APIs, 
communication paradigms (such as REST), common libraries, and best practices. We see a need 
to study application requirements in an ICN environment further and, at the same time, develop 
new APIs and best practices that can take advantage of ICN communication characteristics. 


7.2. Protocols for Content Delivery Network Migration 


A key issue in CDNs is to quickly find a location of a copy of the object requested by an end user. 
In ICN, a Named Data Object (NDO) is typically defined by its name. [RFC6920] defines a 
mechanism that is suitable for static naming of ICN data objects. Other ways of encoding and 
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representing ICN names have been described in [RFC8609] and [RFC8569]. Naming dynamically 
generated data requires different approaches(e.g., hash-digest-based names would normally not 
work), and there is a lack of established conventions and standards. 


Another CDN issue for ICN is related to multicast distribution of content. Existing CDNs have 
started using multicast mechanisms for certain cases, such as for broadcasting streaming TV. 
However, as discussed in Section 6.2.1, certain ICN approaches provide substantial 
improvements over IP multicast, such as the implicit support for multicast retrieval of content in 
all ICN flavors. 


Caching is an implicit feature in many ICN architectures that can improve performance and 
availability in several scenarios. The ICN in-network caching can augment managed CDN and 
improve its performance. The details of the interplay between ICN caching and managed CDN 
need further consideration. 


7.3. Protocols for Edge and Core Network Migration 


ICN provides the potential to redesign current edge and core network computing approaches. 
Leveraging ICN's inherent security and its ability to make name data and dynamic computation 
results available independent of location can enable a lightweight insertion of traffic into the 
network without relying on redirection of DNS requests. For this, proxies that translate from 
commonly used protocols in the general Internet to ICN message exchanges in the ICN domain 
could be used for the migration of application and services within deployments at the network 
edge but also in core networks. This is similar to existing approaches for IoT scenarios where a 
proxy translates CoAP request/responses to other message formats. For example, [RFC8075] 
specifies proxy mapping between CoAP and HTTP protocols. Also, [RFC8613] is an example of 
how to pass end-to-end encrypted content between HTTP and CoAP by an application-layer 
security mechanism. Further work is required to identify if an approach like [RFC8613], or some 
other approach, is suitable to preserve ICN message security through future protocol translation 
functions of gateways/proxies. 


Interaction and interoperability between existing IP routing protocols (e.g., OSPF, RIP, or IS-IS) 
and ICN routing approaches (e.g., NFD and CCNx routers) are expected, especially in the overlay 
approach. Another important topic is the integration of ICN into networks that support 
virtualized infrastructure in the form of NFV/SDN and most likely utilize SFC as a key protocol. 
Further work is required to validate this idea and document best practices. 


There are several existing approaches to supporting QoS in IP networks, including Diffserv, 
IntServ, and RSVP. Some initial ideas for QoS support in ICN networks are outlined in [FLOW- 
CLASS], which proposes an approach based on flow classification to enable functions, such ICN 
rate control and cache control. Also, [ICN-QoS] proposes how to use Diffserv Differentiated 
Services Code Point (DSCP) codes to support QoS for ICN-based data path delivery. Further work 
is required to identify the best approaches for support of QoS in ICN networks. 


OAM is a crucial area that has not yet been fully addressed by the ICN research community but 
which is obviously critical for future deployments of ICN. Potential areas that need investigation 
include whether the YANG data modeling approach and associated NETCONF/RESTCONF 
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protocols need any specific updates for ICN support. Another open area is how to measure and 
benchmark performance of ICN networks comparable to the sophisticated techniques that exist 
for standard IP networks, virtualized networks, and data centers. It should be noted that some 
initial progress has been made in the area of ICN network path traceroute facility with 
approaches, such as CCNxinfo [CNNinfo] [Contrace]. 


7.4. Summary of ICN Protocol Gaps and Potential Protocol Efforts 


Without claiming completeness, Table 1 maps the open ICN issues identified in this document to 
potential protocol efforts that could address some aspects of the gap. 


ICN Gap Potential Protocol Effort 

1-Support of REST HTTP/CoAP support of ICN semantics 

APIs 

2-Naming Dynamic naming of ICN data objects 

3-Routing Interactions between IP and ICN routing protocols 

4-Multicast Multicast enhancements for ICN 

distribution 

5-In-network ICN cache placement and sharing 

caching 

6-NFV/SDN Integration of ICN with NFV/SDN and including possible impacts to SFC 

support 

7-ICN mapping Mapping of HTTP and other protocols onto ICN message exchanges (and 
vice versa) while preserving ICN message security 

8-QoS support Support of ICN QoS via mechanisms, such as Diffserv and flow 
classification 

9-OAM support YANG data models, NETCONF/RESTCONF protocols, and network- 


performance measurements 


Table 1: Mapping of ICN Gaps to Potential Protocol Efforts 


8. Conclusion 


This document provides high-level deployment considerations for current and future members 
of the ICN community. Specifically, the major configurations of possible ICN deployments are 
identified as (1) Clean-slate ICN replacement of existing Internet infrastructure, (2) ICN-as-an- 
Overlay, (3) ICN-as-an-Underlay, (4) ICN-as-a-Slice, and (5) Composite-ICN. Existing ICN trial 
systems primarily fall under the ICN-as-an-Overlay, ICN-as-an-Underlay, and Composite-ICN 
configurations. 
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In terms of deployment migration paths, ICN-as-an-Underlay offers a clear migration path for 
CDN, edge, or core networks to go to an ICN paradigm (e.g., for an IoT deployment) while leaving 
the critical mass of existing end-user applications untouched. ICN-as-an-Overlay is the easiest 
configuration to deploy rapidly, as it leaves the underlying IP infrastructure essentially 
untouched. However, its applicability for general deployment must be considered on a case-by- 
case basis. (That is, can it support all required user applications?). ICN-as-a-Slice is an attractive 
deployment option for upcoming 5G systems (i.e., for 5G radio and core networks) that will 
naturally support network slicing, but this still has to be validated through more trial 
experiences. Composite-ICN, by its nature, can combine some of the best characteristics of the 
other configurations, but its applicability for general deployment must again be considered on a 
case-by-case basis (i.e., can enough IP routers be upgraded to support Composite-ICN 
functionality to provide sufficient performance benefits?). 


There has been significant trial experience with all the major ICN protocol flavors (e.g., CCNx, 
NDN, and POINT). However, only a limited number of applications have been tested so far, and 
the maximum number of users in any given trial has been less than 1k users. It is recommended 
that future ICN deployments scale their users gradually and closely monitor network 
performance as they go above 1k users. A logical approach would be to increase the number of 
users in a slowly increasing linear manner and monitor network performance and stability, 
especially at every multiple of 1k users. 


Finally, this document describes a set of technical features in ICN that warrant potential future 
IETF specification work. This will aid initial and incremental deployments to proceed in an 
interoperable manner. The fundamental details of the potential protocol specification effort, 
however, are best left for future study by the appropriate IETF WGs and/or BoFs. The ICNRG can 
aid this process in the near and mid-term by continuing to examine key system issues like QoS 
mechanisms, flexible naming schemes, and OAM support for ICN. 


9. IANA Considerations 


This document has no IANA actions. 


10. Security Considerations 


ICN was purposefully designed from the start to have certain intrinsic security properties. The 
most well known of which are authentication of delivered content and (optional) encryption of 
the content. [RFC7945] has an extensive discussion of various aspects of ICN security, including 
many that are relevant to deployments. Specifically, [RFC7945] points out that ICN access control, 
privacy, security of in-network caches, and protection against various network attacks (e.g., DoS) 
have not yet been fully developed due to the lack of a sufficient mass of deployments. [RFC7945] 
also points out relevant advances occurring in the ICN research community that hold promise to 
address each of the identified security gaps. Lastly, [RFC7945] points out that as secure 
communications in the existing Internet (e.g., HTTPS) become the norm, major gaps in ICN 
security will inevitably slow down the adoption of ICN. 
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In addition to the security findings of [RFC7945], this document has highlighted that all 
anticipated ICN deployment configurations will involve coexistence with existing Internet 
infrastructure and applications. Thus, even the basic authentication and encryption properties of 
ICN content will need to account for interworking with non-ICN content to preserve end-to-end 
security. For example, in the edge network underlay deployment configuration described in 
Section 4.3.1, the gateway/proxy that translates HTTP or CoAP request/responses into ICN 
message exchanges will need to support a security model to preserve end-to-end security. One 
alternative would be to consider an approach similar to [RFC8613], which is used to pass end-to- 
end encrypted content between HTTP and CoAP by an application-layer security mechanism. 
Further investigation is required to see if this approach is suitable to preserve ICN message 
security through future protocol translation functions (e.g., ICN to HTTP or CoAP to ICN) of 
gateways/proxies. 


Finally, the DOCTOR project discussed in Section 6.2.6 is an example of an early deployment that 
is looking at specific attacks against ICN infrastructure, in this case, looking at Interest Flooding 
Attacks [Nguyen-2] and Content Poisoning Attacks [Nguyen-1] [Mai-2] [Nguyen-3] and evaluating 
potential countermeasures based on MANO-orchestrated actions on the virtualized 
infrastructure [Mai-1]. 
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